Modern corporations and other enterprises are utilizing more and more software based “solutions” in their day to day operations. Computer networks, telephony systems, Internet access, e-mail, personnel record keeping, billing and payroll, etc. all are nearly completely run through software based systems. With this increased software content, corporations and other enterprises have a need to monitor the performance and status of elements of their computer networks to prevent data loss and to maximize resource efficiency. Further, these corporations and enterprises have a need to manage the individual resources, functions, users, etc. which make up these solutions, which determine the operation of these solutions, and who use and are tracked by these solutions.
Currently, many of these enterprise software solutions require that the management thereof be performed through the programs themselves. To support such enterprise system management, the assignee of the instant application developed a management framework called Microsoft® Management Console (MMC). MMC is an extensible user interface that provides an environment for running systems management applications structured as components called snap-ins. MMC is a Windows®-based multiple document interface (MDI) application that makes extensive use of Microsoft's COM (Component Object Model) technology. Both OEMs (Original Equipment Manufacturers) and ISVs (Independent Software Vendors) can extend the console by writing MMC snap-ins, which are responsible for performing management tasks. MMC serves as a host for snap-in-defined user interfaces, but does not limit what the snap-ins can do or how they communicate with the administered services.
MMC does not replace existing enterprise management applications, such as Hewlett-Packard OpenView™ or the IBM Tivoli Management Environment™. Instead, it extends these tools by allowing them to interact with or be packaged as snap-ins that can be accessed from the MMC user interface. For example, an enterprise management application could detect a database event and send an alarm to a snap-in. A system administrator would then see the event in an MMC session and take appropriate action. MMC interacts with snap-ins using several MMC-defined interfaces under the COM standard.
Specifically, snap-ins are implemented as COM in-process (in-proc) server dynamic link libraries (DLLs) supporting one or more of these interfaces and registering themselves appropriately in the MMC registry area. MMC gains access to the snap-in by obtaining a pointer to one of its interfaces. With this pointer, MMC can use the snap-in without understanding its implementation and can depend on it to behave in a consistent manner all the time. COM interfaces also provide a way to extend the functionality of the MMC user interface without dictating how each snap-in performs its particular tasks. Implementation is entirely up to the snap-in. In other words, MMC interfaces allow snap-ins to share a common hosting environment and provide cross-application integration. By using this approach, both software OEMs and ISVs can write administrative applications that are hosted by MMC. This is also true for developing management tools to run in MMC and writing applications to be managed by MMC administrative tools. The design of MMC allows developers to spend less time building and rebuilding windowing frameworks for tools and more time on the tasks associated with building real management functionality.
As will be recognized, the management console itself does not supply any management behavior, but instead provides a common environment for these software modules commonly called “snap-ins.”. The snap-ins define the actual management behavior available to an administrator through the management console. The management console organizes and coordinates the snap-ins and provides an integrated user interface through which the administrator can invoke the snap-ins to provide their respective management behavior. For example, the management console may be used to show the computers in a network, or the users of a specified server in a distributed system.
Typically, the management console includes a user interface for selecting a management behavior provided by the snap-ins, and a node manager to interact with snap-ins and to coordinate the operations of the snap-ins through specified programming interfaces. The snap-ins to be used with the management console are registered with a registry of the operating system, and graphic interface items corresponding to the snap-ins may be placed in the user interface window of the management console. When the user selects a management behavior through the interface window, the node manager invokes the corresponding snap-in to provide the selected management behavior.
As an example of this management, attention is now directed to FIG. 2 which illustrates a management framework including MMC. As may be seen from this FIG. 2, MMC 60 is being utilized to manage a dynamic host configuration protocol (DHCP) server 62 which, as will be recognized by those skilled in the art, is a network service. MMC 60 utilizes a DHCP snap in 64 to perform its management functions as described above in coordination with the DHCP management application program interface (API) 66. As will also be made clear from reference to this FIG. 2, the management of the DHCP server 62 may also be accomplished through the use of NetShell 68 to provide a command line interface management option. NetShell is also known is Netsh exe and is a tool an administrator can use to configure and monitor Windows 2000-based computers at a command prompt. As will be recognized by one skilled in the art, NetShell 68 implement helper functions 70 which through the management API 66 allows command line interface management of the DHCP server 62. With the Netsh exe tool an, administrator can direct the context command he or she enters to the appropriate helper, and the helper then carries out the command. A helper is a Dynamic Link Library (.dll) file that extend, the functionality of the Netsh exe tool by providing configuration monitoring and, support for one or more services, utilities or protocols. The helper may also be used to extend other helpers.
While this framework performs quite well, certain aspects thereof are available for improvement. Specifically, each of these components, MMC 60 for Windows based management or NetShell 68 for command line interfaces, implements its own syntax and semantic checks for the various management tasks which are performed therethrough. This results in a significant amount of redundancy due to the fact that the same work has to be done for both MMC 60 and NetShell 68. This can also lead to serious inconsistencies if any change is done in one place and not reflected in the other. The result is an increased cost of maintenance of the enterprises and an overall increase in the cost of ownership because one needs to ensure that any time a change is made through one interface, the code for the other interface is also updated with the new change Specifically, for each particular attribute, range, value, etc. change through either of these interfaces a system administrator must be concerned with the effect that such change has on any other attribute which may be managed differently through one interface as opposed to the other. Further, since NetShell 68 and MMC 60 are disparate pieces of code, each present a different user experience when performing management tasks therethrough. These different user experiences include possibly disparate error messages and steps through which the management is performed. This different user experience also includes the amount and type of help information which may or may not be provided for the various tasks performed therethrough. An additional problem with the management framework illustrated in FIG. 2 results from the fact that the interfaces between the management API 66 and the helper 70 and snap in 64 are C interfaces. As a result, there is no portability of management control through this architecture, prohibiting the management from another machine.
Currently, the computer industry is developing a concept of Web-Based Enterprise Management (“WBEM”) to overcome some of the problems existing with the prior architecture. WBEM is an industry initiative to develop a standardized, nonproprietary means for accessing and sharing management information in an enterprise network. The WBEM initiative is intended to solve the problem of collecting end-to-end management and diagnostic data in enterprise networks that may include hardware from multiple vendors, numerous protocols and operating systems, and a legion of distributed applications The WBEM industry-wide initiative is to develop a standardized technology for accessing management information in enterprise environments to help companies lower their total cost of ownership of these enterprise systems.
Microsoft has developed WMI (Windows Management Instrumentation) so that developers may build applications capable of accessing all of the management information available on Microsoft Windows platforms. This includes applications that access machine resources such as system memory, available hard disk space, and printer installations, that inventory current applications installed on a client, and that administer an application on a remote application server, in process events such as simple network management protocol (SNMP) traps, and events recorded in the windows NT event log. The WMI technology enables systems, applications, networks, and other managed components to be represented using the Common Information Model (CIM), as standardized by the Desktop Management Task Force (DMTF). CIM can model anything in the managed environment regardless of data source location.
Typical sources for management information include databases and the underlying system. For example, a database may be queried by a management application, or a system call may be made to determine the state of some device, e.g., the free space of a disk. Alternatively, some management applications interface directly with instrumentation that can pull information from device drivers or other software components. For example, a management application may communicate with remote disk drive software to determine how much free space remains on a network drive. As can be readily appreciated, the wide variety of management applications and resources, protocols, formats, frameworks, and so on made it difficult and complicated for management applications and the users thereof to obtain the desired information.
The founding companies of the WBEM initiative developed a prototype set of environment-independent specifications for how to describe and access any type of management instrumentation, including existing standards such as Simple Network Management Protocol and Desktop Management Interface. As described above, a core component of the specification is a standard data description mechanism known as the Common Information Model (“CIM”). The CIM specification describes the modeling language, naming, and mapping techniques used to collect and transfer information from data providers and other management models. The Windows Management Instrumentation (“WMI”) system is compliant with CIM and the WBEM initiative. A simplified block diagram of WMI's Architecture is illustrated in FIG. 3.
A significant improvement for accessing and returning management information is the result of the use in WMI 72 of a common information model object manager (CIMOM) 74 provided to isolate management applications 76, 78, 80, 82 from the various sources of management information, while providing a single, uniform way to access the information. This CIMOM 74 is decribed in detail in a co-pending application entitled “Object Manager for Common Information Model” filed Feb. 6, 1998 as application Ser. No. 09/020,146, now abandoned, and continuation filed February 13, 2002 as application Ser. No. 10/076,166. With the CIMOM 74, each management application 76, 78, 80, 82 submits queries to the CIMOM 74 in a uniform way. The CIMOM 74 then communicates with one or more sources of the information, known as providers 84, to return an appropriate reply. The CIMOM 74 is intelligent in that it can decompose queries into requests from multiple providers 84 and synthesize the results into a single response, filter excess information, work with the capabilities of the providers, and so forth.
In a common information model (CIM) installation, a process acting in the role of a client (e.g. 80) makes management requests, while a process acting as a server, i.e., a CIM object manager, or the CIMOM 74, satisfies each request via one or more providers 84 and returns an appropriate response via uniformly rendered managed objects. The client process (e.g., a management application 80) communicates management information requests through a proxy 72 to the CIMOM 74. At least part of the communication is preferably via COM (Component Object Model) and/or DCOM (Distributed Component Object Model), i.e., by invoking methods of objects in the CIMOM server 74 over an underlying protocol such as TCP. Additionally, the client process 80 may communicate with the CIMOM 74 using the HyperMedia Management Protocol (HMMP). HMMP provides management services across platform boundaries by defining a common network access model, a common schema, and a common security model.
By way of example of how management information is exchanged in WMI 72, the client process 80 starts a request, which is appropriately packaged up by the proxy 72. The request is received by the CIMOM 74, which is a component on a server that implements a large subset of the communication protocol, and which switches roles so as to act as a proxy on behalf of client process requests. As part of its function, the CIMOM 74 passes the client process requests to one or more appropriate servers known as object providers 84 (or simply providers). Providers 84 are the sources of management information, and typically obtain their information directly from a system resource such as a hardware device or database, although a provider 84 may obtain some of its provided information from another provider, e.g., via the CIMOM 74. By way of example, one type of provider 84 may be implemented in a software driver or the like supplied by a vendor to accompany a hardware device such as a disk drive.
In order to service a request, the CIMOM 74 accesses a CIM repository 86 (database) in order to determine which object provider or providers to contact (if any). More particularly, when the client process 80 sends a request to the CIMOM 74, the client process 80 will access the CIM repository 86, which may have the information therein if static, and/or will provide the information necessary for locating the appropriate provider 84 or providers which can satisfy the request. Thus, the CIMOM 74 will either directly satisfy a request or in essence become a client process itself and forward the request to an appropriate provider 84.
Through the CIMOM 74, client processes 80 are relieved of the burden of locating and directly managing a multitude of devices on the network. Instead, the CIMOM 74 hides the management complexity by distributing the request to the appropriate providers 84. The providers gather the necessary data from the devices using vendor or protocol-specific mechanisms such as DMI, SNMP, CMIP or a proprietary mechanism, and return the data to the requesting the CIMOM 74.
Providers 84 are components (e.g., dynamic link libraries, or DLLs) which are essentially more primitive in nature than the CIMOM 74 itself. As a result, in order for the CIMOM 74 to present uniform capabilities to the client process 80, the CIMOM 74 may simulate any operations not directly supported by a provider 84, by executing more and more primitive requests until a request is understood by the provider 84. The CIMOM 74 then synthesizes the results and returns them to the client process 80 as though the provider 84 or providers had been capable of the original complex request submitted by the client process 80. The CIMOM 74 is capable of retrieving both the static and dynamic information from various sources including the CIM database 80 and/or appropriate providers 84, and returning the object instance to the client process 80 (application).
The CIMOM 74 is capable of receiving potentially high level SQL queries, decomposing those queries as necessary, and communicating with a variety of sources, possibly in a series of very primitive operations, to produce a result. The operations are transparent to the client process 80, as the result is returned in the same manner regardless of the sources that supplied the information. For example, a query such as—select*from LogicalDisk where FreeSpace<20000000—intends to have returned only instances that meet the less than twenty megabyte criteria, and not all instances of the LogicalDisk class. If the provider 84 or providers of this information are unable to limit their retrieval based on these criteria, the CIMOM 74 provides the correct result set by a post-retrieval filtering operation. The CIM object manager 74 thus performs operations that complement the capabilities of providers in order to uniformly render managed objects to management applications 80. Because some providers have substantially more capabilities than other providers, the CIMOM 74 attempts to operate each provider with its maximum capabilities, lowering its level for requesting information from a provider until the provider can satisfy the request, e.g., by reducing the complexity of a query for that provider.
Unfortunately, while this management framework provides a substantially improved model over its predecessors, it still includes areas that may be improved. Specifically, while the lack of portability of the prior management model has been overcome, each of the methods of providing user interface to the management system still performs their own syntax and semantic checks. As discussed above, this results in redundancy between each of the various user interfaces, and may lead to inconsistencies as variables are changed through one interface, and may not be reflected in others. Additionally, as with the prior management model, the user experience may differ significantly upon accessing the management system through each of the different user interfaces as they each generate their own help strings, etc. Therefore a need exists to provide a management framework which eliminates the redundancy and inconsistencies which may result from the current management framework provided by the WBEM management systems, but which, at the same time, utilizes the basic WBEM management system framework as a basis for the system. There further exists a need in the art for a WBEM based management system which allows for utilization of various user interfaces and which is extensible to support new user interfaces as they become available, while at the same time providing a consistent user experience.